As the server market is headed towards consolidation, high-end systems supporting partitioning of the server to smaller systems running multiple instances of Operating Systems (OS) are gaining acceptance.
Present day systems support two types of partitioning mechanisms:                Hard partitions—the partitions are electrically isolated, have their own CPU, Memory and IO resources. Hardware faults in these partitions are self contained and do not affect the other partitions within the same server complex. The users can choose to dynamically expand resources within a hard partition by adding more resources which include CPUs, memory and IO slots. Usually the hard partitions are expanded by adding a group of CPUs, memory and IO to the existing partition.        Virtual Partitions—these are software partitions created within a hard partition. These partitions share the resources within the “hard partition” and avoid stepping on each other's area by a low level partition manager (or monitor) controlling the visibility of resources to different instances of Operating systems executing on different virtual partitions. These partitions provide software fault isolation across OS instances.        
Technologies exist to help add resources (CPU, memory and I/O) to pre-existing virtual partitions. Likewise, it is possible to migrate resources between the virtual partitions of an existing system (or hard partition).
Partitioning solutions from vendors, such as HP and IBM, help customers consolidate their systems and drive system utilization levels up by employing load balancing and resource migration utilities over the virtual partitions to meet the varying demands of applications deployed over the consolidated and partitioned servers.
Current partitioning solutions provide almost instantaneous migration/addition of CPU resources to a partition—either from a free pool of CPUs or by stealing from a neighbouring partition where the CPU is perhaps underutilized.
However, migration of memory or IO resource from use by one partition to another often occupies a significant amount of time, running into several minutes and at times hours.
Unfortunately, applications cannot perform well when only one of the key resources it needs is satisfied—only the CPU. They are usually hungry for more memory which may not be immediately available.
One existing method to move memory between two virtual partitions uses the following steps (Partition One is the partition to move memory to and Partition Two is the partition from where the memory is being taken away):    i) Identify the physical memory that can move from Partition Two to Partition One.    ii) Clean the identified physical memory range by moving data within the range to other pages in Partition Two or swapping out to disk.    iii) Ensure that the memory management subsystem of the OS running on Partition Two removes the physical memory range related information from its internal data structures (to prevent “stamping” on the memory area by Partition Two after the memory migrates out of that partition).    iv) Update the memory management subsystem of the OS running on Partition One to permit access to the new physical address range.
A significant delay occurs between when Partition One requires the memory and when Partition Two can deliver the memory. This delay is mostly due to step (ii).
US 20030212873A1 describes method and apparatus for managing memory blocks in a logical partitioned data processing system. This document describes how memory blocks from one partition are made global and then added to a second partition.
This method does not describe the immediate transfer of memory from one partition to another to meet instant demand.
US 20030217153A1 describes a computer system with dynamically configurable capacity.
This document describes a Capacity on Demand (COD) system to meet the processing needs of partitions by adding in Field Replaceable Units (FRU)s.
This method therefore covers the addition of physical components to meet memory needs rather than reallocating existing memory between partitions.
It is an object of the present invention to provide a method and system for managing memory across a plurality of partitions which overcomes or at least ameliorates a number of the disadvantages of existing methods mentioned above, or to at least provide a useful alternative.